Dealing with the negative feedback
Dealing with the negative feedback - Moderated by Daniel Hinojosa, SourceForge.net (d.) At SourceForge.net, we sell ads to make money. In the OSS community, this is often frowned upon. With that, when we introduce new programs, the question is, how do we manage the negative feedback from community members? Initially, we make sure that we listen and adjust when we can. Others in the room (over 20 participants), offered the following ideas: Be transparent; detail why does it cost so much, detail costs, speakers, for, wide audience, etc. Even a blog post - this is where we get the money from. Benefits for you (site user), in exchange here is what you get - instead of one on one, use one to many and see if folks have other ideas. Do I (community manager) understand what the ground rules are in and of the community? It's a catch 22 situation. Can we engage the community to help suggest to us to do things? Ask the community, What would you like to see - how would it work better for you? When people have ideas of how to make improvements - know where the sticky points are - then follow up. CM from Java.net: hold a mini conference for the community, go over the last year - go over things that were done in the year, Change the focus of where we went - they do it at Java One - do it early, host a brunch - brainstorms, 3 to 4 hours, give folks an opportunity- the act of listening is key - they know they are being heard. They make it a big thing - they make it a big part, we don't implement everything - we had a give and take. A team that has a project in the Google Summer of Code, they hold a summit each year, then they have a feedback session - some things we can't do - the act of letting them tell us, don't like saying no, but they say it - it's been heard. 2 sides need to be in sync - they need to understand why you came to that conclusion solutions we looked at - quick trip down the logic path, this is what we did, why, etc. If you (audience) have better ideas we want to hear it - won't make problem go away, but it assures the audience / feedback was heard. One user wanted to know how do you do face to face virtually? IRC is favored. Tools - we use the issue key for bugs software, but for comments - push people to the support queue, list their problem, why things are the way it is, good paper trail behind it - worked well. Another user indicates that for virtual meeting, they use Meetbot - certain words allow for writing meeting notes / minutes. Goes immediately into meeting minutes. Doing a brainstorming meeting, you can capture ideas. Chap from HP & OpenStack - likes Meetbot - where do you capture info for Q&A? User voice for all customer feedback - Up-vote for things, Feature request form - most feedback comes from Twitter - we've seen in our Q&A that some folks are seeing that effort. Voting and negative feedback - heavily voted issues are negative feedback - Redhat disabled voting in Bugzilla. Feedback trying to make it through in the voting system. making feedback easy - clicking an up or down is easy. On quantifying feedback form a community of potentially millions, there is a multiplier against each vote represents - how do you scale the feedback? Finding the multiplier is key. Lots of folks don't participate in the bug tracking systems, might help to find out how important each issue is - each community has their own multiplier. When you implement these features, based on your feedback - On the thumbs up down - folks want to know why they were down voted - folks don't always agree, but he data is there to have to deal with and understand in some form. When 1M people vote to take have a certain thing happen on a site, the Community Manager needs to make sure the business is comfortable with what they are going to hear - if we let the feedback sit w/no action, it's going to become a bad thing. Putting up a voting systems admits that community opinion matters. Have to dig deeper to understand the crux of an issue. If the issue is site usage, you might learn that simple change of placement of functions can make a huge difference. At what point do you stop validating with a level of effort; explain it once, say in a blog, an article, something, and then redirect to the explanation when the issues arises again. Don't renew the explanation effort. What's the tipping point of applying resource to managing negative feedback? (rhetorical question) Innovation; you want ideas, you get a group of people to gate keep ideas - criticism - "lighthouse" customers, are ahead of others. General feedback email - forums - complaints / criticisms, new ideas, Know who the haters / trolls are, opt to not respond as these can simply be attention getters - keep an eye on it and do not reward - may not be a troll - we're not going to rewrite - we're doing this, etc. User note: What If blogger has a big following? We're ethical on this point, we have explained how we came here - but don't deal with it every time. When community - not users but developers. A vocal minority - can you say no to that population - contributing 30 to 40% of that development? Drupal is a meritocracy - some folks are a little more toxic - do a lot of dev, An Ubuntu developer - meritocracy, we have a financial backer - they steer the ship, pseudo - benevolent dictator . An Anti-pattern, open stack governance based on problems that were noticed in other efforts. Avoided this so far, not going to be solved by dealing with haters & trolls. How do you deal with the negative? One developer notes that customers have choices; content that is trying to drive is valid or not, they have every right to their opinion, doesn't make them an evil troll, trolls go beyond content to attacking person, their intelligence, take it back to topic and away from personal attacks. As community managers, advocate what would be best for the greater project. You're going to do what works for your company. You've done your job, don't let vocal minority dominate my life. There will always be haters, folks that don't think it will work. Have to stick to the mission, goal and what are you driving towards. Observation: what are the things we "kiss to Jesus?" What are the things that we can modify, and then the tertiary things that we have to analyze more closely? Ask a community member who has more "weight" to weigh in publicly. Java community process - there was a feeling of corporate control with vocal minorities - bring well respected user groups - put them on the decision panel. Group went from being the vocal minority to becoming the group that had to talk to the now vocal minority. Folks are committed to making sure the feedback persists. Vocal minorities representative codifies the feedback from the community - allows them to establish a story. Tell the community things that will happen before you announce them. When a company has to hold back information for whatever reason, the Community Manager needs to be able to manage the data from the company. One Community Manager notes that his job is that when you come into the room with a problem to me (his management), that I (manager) get it to a stage where you (CM) can take that back out of the room to solve. Taking complainers, bring them in, explain the situation, then send them back out to help solve the problem. Make them wear your shoes a little bit. The community knows who the trolls are - they get to recognize the regulars and those that may be less than appropriate. Some may have it in for us - you can look at their blog and suss them out a bit - not every troll is created equal. One member feels bad in ignoring a troll. We defined troll from Wikipedia: http://en.wikipedia.org/wiki/Troll_(Internet) - clarification that someone who is a fan boy and offers criticism is to be held in regard. A community manager needs to help clarify this user. Formality is a good tool to get your point across. Don't take feedback personally. If someone doesn't like what we're doing, is not about you; try to resound to that question from a professional perspective. Get others to review messages if you are in a bad mood so that you have that balance. Wait 30 minutes from typing a message that is in response to such input from the community, get someone else to review it with / for you so that you are balanced. How can you use tools you have to structure a dialog? Worse than email is making a blog post. A blog has so much statement in it. Even if "proposing", it sounds like, this is what we ARE going to do. In the 80's was more common to have user groups. As corporate folks, we had little to do in such rings - was about product direction and getting the pulse of the community.